Associate Cloud Engineer Practice Exam — Associate Cloud Engineer

This question assesses core Associate Cloud Engineer knowledge of secure, scalable access management for Compute Engine instances, aligned with GCP best practices for operational efficiency and auditability. The scenario has two mandatory requirements: first, low-overhead credential deployment for a large fleet of instances, and second, the ability to trace instance access to individual team members, with all users already having existing Google accounts. The suggested answer C leverages GCP's native OS Login feature to meet both requirements. By linking each user's SSH public key to their existing Google account and granting the compute.osAdminLogin role to the team's Google group, you eliminate the need to manually deploy or update SSH keys across individual instances. All SSH access events are tied directly to the user's unique Google identity, so security teams can easily audit access via Cloud Audit Logs, fulfilling the traceability requirement. This approach also scales seamlessly as team members join or leave, as access is controlled via group membership rather than per-instance key updates. Option Analysis: A. Incorrect. Sharing a single private key across all team members makes it impossible to trace access to individual users, violating the security team's audit requirement. Additionally, adding the public key to each instance's metadata is operationally inefficient for a large number of instances, as any key rotation or team change requires manual updates across every instance. B. Incorrect. While this approach uses individual user keys, deploying keys to each instance via configuration management creates significant operational overhead, as you must maintain an up-to-date key list and push changes to all instances every time a team member joins or leaves. This also lacks native integration with GCP's audit logging for identity traceability compared to OS Login, and does not leverage existing Google identity infrastructure as required for optimal efficiency. C. Correct. This approach uses GCP's OS Login feature, a native Compute Engine capability designed for scalable, secure SSH access management. Linking each user's public key to their Google account ties their SSH identity to their corporate user account. Granting the compute.osAdminLogin role to the team's Google group grants administrative SSH access to all relevant instances without manual key deployment to individual VMs. All access events are logged with the user's unique Google identity, enabling full auditability of who accessed each instance, meeting both the operational efficiency and security requirements of the scenario. D. Incorrect. Using a shared project-wide SSH key pair means all team members use the same credentials, making it impossible to identify individual users who accessed an instance, which fails the security team's traceability requirement. Project-wide shared keys also introduce unnecessary security risk, as a compromised private key gives access to all instances in the project, and key rotation requires updating the project metadata and coordinating distribution of the new private key to all team members. Key Concepts: 1. OS Login: A native Compute Engine feature that manages SSH access to instances using Cloud IAM, eliminating the need to manually distribute and update SSH keys across VM fleets. It associates SSH keys with individual Google Cloud identities, enabling centralized access control and auditability. 2. Compute Engine OS Login IAM Roles: The compute.osAdminLogin role grants users administrative (sudo-enabled) SSH access to instances when OS Login is enabled, while the compute.osLogin role grants standard non-administrative access, supporting least privilege access principles. 3. Cloud Audit Logs for Compute Engine Access: When OS Login is enabled, all SSH access attempts are logged in Cloud Audit Logs with the associated user's unique Google identity, allowing security teams to track, investigate, and report on individual user access to instances for compliance and incident response. References: About OS Login, Set up OS Login, https://cloud.google.com/compute/docs/oslogin/set-up-oslogin

This question tests knowledge of valid CIDR ranges for cloud VPCs and subnet sizing as required for the Associate Cloud Engineer certification. All major cloud providers, including Google Cloud, require VPC and subnet CIDR blocks to use private, non-publicly routable address ranges defined in RFC 1918 to avoid conflicts with public internet addresses. The size of a CIDR block is inversely related to its prefix length: a shorter prefix (lower numeric value after the slash) corresponds to a larger block with more available host addresses. The question requires the largest possible valid subnet range for a custom VPC, so we first eliminate invalid non-private ranges, then select the largest remaining private range. The 10.0.0.0/8 range is the largest valid RFC 1918 private range, so it is the correct choice. Option Analysis: A. 0.0.0.0/0 is a special purpose CIDR block that represents all IPv4 addresses. It is only used in route tables to define a default route for traffic that does not match any more specific route entries. No cloud provider allows this CIDR to be assigned as a VPC or subnet range, so this option is invalid. B. 10.0.0.0/8 is the largest private IPv4 range defined in RFC 1918, containing 16,777,216 total addresses (16,777,214 usable host addresses after accounting for reserved cloud network addresses). It is fully supported as a VPC and subnet CIDR across all cloud platforms, and is the largest valid option provided, so this is the correct answer. C. 172.16.0.0/12 is a valid RFC 1918 private range, but it only contains 1,048,576 total addresses, which is 16 times smaller than the 10.0.0.0/8 range. It does not meet the requirement for the largest possible range, so this option is incorrect. D. 192.168.0.0/16 is the smallest RFC 1918 private range listed, with only 65,536 total addresses. It is significantly smaller than both the /8 and /12 private ranges, so it does not meet the requirement, making this option incorrect. Key Concepts: 1. RFC 1918 Private Address Ranges: This standard defines three reserved non-public IPv4 ranges for use in private networks, including cloud VPCs, to prevent address conflicts with public internet resources. The ranges are ordered by size from largest to smallest as 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16. 2. CIDR Block Sizing: The prefix length of a CIDR block (the number following the slash) determines the number of available host addresses. Each decrease of the prefix length by 1 doubles the number of available addresses, so shorter prefixes correspond to larger network ranges. 3. VPC CIDR Restrictions: Cloud providers enforce rules for valid VPC and subnet CIDR blocks, prohibiting use of special-purpose ranges such as 0.0.0.0/0, loopback addresses, and public IP ranges to ensure proper network routing and avoid address collisions. References: Virtual Private Cloud (VPC) Network Overview, https://cloud.google.com/vpc/docs/vpc#ip-ranges RFC 1918: Address Allocation for Private Internets, https://datatracker.ietf.org/doc/html/rfc1918

This scenario requires a cost-effective managed relational database solution for a small single-region operational dataset with point-in-time recovery (PITR) support. Core Associate Cloud Engineer knowledge dictates matching database services to workload size, cost constraints, geographic requirements, and recovery needs. Cloud SQL is the optimal relational service for small to medium non-global operational workloads, as it offers lower entry costs than Cloud Spanner. For Cloud SQL MySQL instances, enabling binary logging activates PITR functionality, which captures all database changes to allow restoration to any precise timestamp within the configured log retention period (up to 7 days). This approach directly addresses every requirement in the scenario: it is cost-efficient for small datasets, operates in a single geographic region, and delivers the required PITR capability. Option Analysis: A. Correct. Cloud SQL is a fully managed relational database designed for cost-effective deployment of small to medium operational workloads in single regions. Enabling binary logging for Cloud SQL MySQL instances is the required configuration to activate point-in-time recovery, which directly satisfies the core requirement in the scenario. This option meets all stated constraints and needs. B. Incorrect. Creating failover replicas for Cloud SQL enables high availability by providing a standby instance that takes over traffic during zone or instance outages, but it does not enable point-in-time recovery. Failover replicas also add unnecessary cost for a use case that does not specify high availability requirements, making this option inappropriate. C. Incorrect. Cloud Spanner is a globally distributed relational database built for large-scale, high-throughput, mission-critical workloads. Even a 2-node regional Spanner instance is significantly more expensive than Cloud SQL for a small operational dataset, violating the cost-effectiveness requirement. This option is unnecessarily costly and overprovisioned for the stated use case. D. Incorrect. Multi-regional Cloud Spanner deployments are designed for global workloads that require cross-region high availability and low latency for distributed users. They are far more costly than regional Cloud SQL instances, making them not cost-effective for a small single-region dataset. This option also does not address the PITR requirement any better than the lower-cost Cloud SQL option, so it is incorrect. Key Concepts: 1. Cloud SQL Point-in-Time Recovery Configuration: For Cloud SQL MySQL instances, PITR is enabled via binary logging, which retains transaction logs for a user-defined period up to 7 days, allowing restoration to any timestamp within that window. This is a core data protection feature for operational relational workloads on GCP. 2. Relational Database Service Selection: Cloud SQL is optimized for small to medium, single or multi-region relational workloads with predictable, low entry costs, while Cloud Spanner is designed for enterprise-grade, large-scale, global or high-throughput workloads that require horizontal scaling and 99.999% availability, making it significantly more expensive for small use cases. 3. High Availability vs Data Recovery Features: Failover replicas are a high availability feature that minimizes downtime during outages, while PITR is a data recovery feature that restores data to a specific timestamp to recover from accidental data deletion, corruption, or unwanted changes. These features address distinct business requirements and are not interchangeable. References: Point-in-time recovery | Cloud SQL for MySQL, https://cloud.google.com/sql/docs/mysql/backup-recovery/pitr Choose a relational database | Google Cloud

The question requires configuring autohealing that recreates unresponsive Compute Engine VMs running across multiple zones for a network load balanced deployment, with the fewest steps possible, and uses a threshold of 3 failed 10-second probes to trigger recreation. Autohealing that recreates unhealthy instances is a native feature of Google Cloud Compute Engine Managed Instance Groups (MIGs), not of load balancer configurations alone. The suggested answer directly addresses all requirements: a managed instance group supports multi-zone deployments natively, and an autohealing health check configured on the MIG can be customized to match the required probe interval and failure threshold, triggering automatic recreation of instances that fail the health check. This configuration requires no unnecessary extra resources, meeting the minimal steps requirement. Option Analysis: A. Incorrect. First, the option specifies an HTTP load balancer, which is a Layer 7 global load balancer, not the network Layer 4 load balancer referenced in the scenario. Second, health checks configured on a load balancer backend only stop routing traffic to unhealthy instances, they do not trigger recreation of VMs, which is the core requirement of the question. This option does not meet the need to recreate unresponsive instances. B. Incorrect. This option also uses an HTTP load balancer which is not aligned with the network load balancing scenario. Configuring a balancing mode and maximum RPS only controls traffic distribution across backend instances, and has no relation to autohealing or VM recreation. This option does not address the core requirement at all. C. Correct. Managed Instance Groups (MIGs) are the Google Cloud resource purpose-built for managing groups of identical Compute Engine instances, including native autohealing functionality. Configuring an autohealing HTTP health check on the MIG allows you to define the required 3 failed 10-second probe threshold, and the MIG automatically recreates any instances that fail the health check. MIGs support multi-zone deployments natively, and this configuration uses the fewest steps to meet all stated requirements. D. Incorrect. Autoscaling and autohealing are separate, independent features of MIGs. Autoscaling adjusts the total number of instances in the group based on load metrics, while autohealing recreates individual unhealthy instances to restore functionality. Enabling autoscaling does not turn on autohealing, so this option does not meet the requirement to recreate unresponsive VMs. Key Concepts: 1. Managed Instance Group (MIG) Autohealing: A Compute Engine feature that automatically recreates unhealthy instances in a MIG based on configurable health check thresholds, to maintain application availability. This is the only native GCP way to automatically recreate unresponsive Compute Engine instances. 2. Health Check Parameter Customization: Both load balancer and autohealing health checks support configurable parameters including probe interval, failure threshold, success threshold, and probe type, to match application responsiveness requirements. 3. Load Balancer vs Autohealing Health Check Differences: Load balancer health checks only control traffic routing, stopping traffic to unhealthy instances but leaving them running. Autohealing health checks for MIGs trigger full deletion and recreation of unhealthy instances to restore functionality. References: Setting up autohealing for managed instance groups, Health checks overview, https://cloud.google.com/load-balancing/docs/health-checks

This question aligns with the Associate Cloud Engineer domain of managing GCP resource access and CLI configurations, specifically focusing on GKE cluster configuration review for inactive gcloud profiles with minimal steps. The requirement to review a configured GKE cluster from an inactive gcloud configuration leverages the separation between gcloud global configurations and kubectl Kubernetes access contexts. The correct approach avoids modifying the active gcloud configuration entirely, instead using kubectl's native context management to directly retrieve the required cluster details, which meets the minimal step requirement while returning full GKE cluster configuration data. Option Analysis: A. Incorrect. The gcloud config configurations describe command only outputs high-level gcloud properties such as default project, zone, and basic default cluster identifier, but does not return the full configured GKE cluster details including access endpoints, certificate authority data, and credential information needed to fully review the cluster configuration. B. Incorrect. While activating the inactive gcloud configuration and listing gcloud properties returns basic GKE identifiers, this approach requires modifying the active gcloud configuration which adds unnecessary steps, and gcloud config list does not output the full Kubernetes cluster configuration details. It fails to meet the fewest steps requirement. C. Incorrect. The kubectl config get-contexts command only lists high-level metadata for existing kubectl contexts, including context name, associated cluster name, user, and default namespace. It does not display the full configuration details of the GKE cluster itself, so it is insufficient for a complete review of the configured cluster. D. Correct. GKE cluster access configurations are stored as kubectl contexts in the kubeconfig file, with each GKE cluster linked to a gcloud configuration having a unique context accessible even if the parent gcloud configuration is inactive. Running kubectl config use-context switches to the relevant context without modifying the active gcloud configuration, and kubectl config view returns the complete GKE cluster configuration including endpoint, access credentials, and cluster settings. This approach uses the fewest possible steps and delivers the required cluster configuration details. Key Concepts: 1. gcloud Configuration and kubectl Context Separation: gcloud configurations store global GCP CLI settings, while GKE cluster access details are stored as independent kubectl contexts in the kubeconfig file. These contexts are accessible without activating the associated gcloud configuration, enabling efficient resource-specific reviews. 2. Minimal CLI Operational Best Practice: For service-specific configuration reviews, using service-native CLI tools (kubectl for GKE) avoids unnecessary changes to global gcloud state, reducing operational overhead and risk as expected for Associate Cloud Engineer workloads. 3. GKE Access Configuration Storage: GKE cluster access details including endpoints, CA certificates, and user credentials are persisted in the local kubeconfig file, not in gcloud configuration files, so kubectl can retrieve these details independently of gcloud's active configuration state. References: Configuring cluster access for kubectl, https://cloud.google.com/kubernetes-engine/docs/how-to/cluster-access-for-kubectl Organizing gcloud CLI configurations, https://cloud.google.com/sdk/docs/configurations